Distributed denial of service (“DDOS” or “DDoS”) attacks present security and availability issues for many organizations, and in particular for enterprises engaged in content delivery services. In a DDOS attack, many distributed hosts (usually personal computers infected with malware) flood a targeted system with traffic, such as HTTP requests directed at a web server under attack. When such a server is overloaded with connections, new connections can no longer be accepted, and the server effectively is unavailable. Such attacks, and the resulting unavailability, can produce several adverse consequences for the operator of the server, including loss of reputation, potential loss of business or revenue, and substantial bandwidth costs.
One technique for mitigating DDOS attacks on networks attached to the Internet by passing network traffic addressed to the attacked network through high- capacity networks with “traffic scrubbing” filters. These high-capacity networks have sufficient capacity to withstand the attack, and the traffic scrubbers can filter out the attacking traffic while forwarding desirable traffic to the intended destination. Several companies have developed network based appliances that can act as traffic scrubbers; such devices use a variety of techniques to determine desirable network traffic from undesirable (attack) network traffic.
Many content providers and web hosting providers, however, use a technique called “anycasting” to provide load distribution (and other features) by allowing a group of servers (e.g., web servers, domain name system (“DNS”) servers, etc.) all to respond to requests on a single IP address. For high-volume services, such as DNS services, web services, etc., such anycasting techniques can allow a provider to respond to many more requests than a single server could handle, while still benefiting from the ease-of-use of a single IP address to handle such requests. While data scrubbers can be anycasted, both anycasted and non-anycasted (unicast) scrubbers can cause issues with returning (on-ramping) the clean traffic back to the anycast service (e.g., DNS servers, web servers, etc.). A single scrubber will return all the clean traffic it encounters back to the “closest” system offering the service. However, most anycast services are designed to manage a small percentage of the overall traffic for that service. For example, in an anycasted DNS service with 20 servers, each server can handle 1/20th, or, in other examples, 1/10th (more likely), of the total overall service requests. Hence, if the data scrubber infrastructure comprises four scrubbing centers, each of the four scrubbing centers would send ¼th of the traffic to the closest anycasted server, which can only handle 1/10th of the service requests, causing server performance to degrade or fail. Further, because the scrubbers often are not as geographically dispersed as the DNS servers, the scrubbers get traffic aggregation problems. Traffic is aggregated in a much higher concentration at downstream servers nearest the scrubbers, presenting problems on balancing the load on the servers.
There is a need for more robust solutions to provide the benefits of data scrubbing within an anycasted environment.